If the bug results in a deterministic handling across various instances, it is not a problem. Otherwise, a fork can occur. Hence, why not terminate the sidecar when a bug is identified as it can be serious. Otherwise, we can remove the following lines:

	if b.txStatus[txNum] != statusNotYetValidated {
		// This can never occur unless there is a bug in the relay or the coordinator.
		return errors.Newf("two results for a TX [blockNum: %d, txNum: %d]", b.block.Header.Number, txNum)
	}

Yes. I agree we should terminate on a bug. We should terminate here as well.
The issue is having to propagate the error only for a case that should never happen.
Will it be acceptable to panic in such a case? Using logger.Fatal()? What do you think?

Sure, I am fine with a panic here though the effective go recommendation is to propagate the error to the main. At least, we should print the stack trace here.

I went with propagation to avoid panicking on tests.

Why don't we directly set the final status here itself rather than calling rejectTx(). Otherwise, it is possible to callhdr.TxID on nil. Hence, I feel this is bit fragile. In fact, the debug() in IsStatusStoredInDB is accessing hdr.TxID and can result in panic if debug log is enabled. If you want to retain the call to rejectTx(), there has to be some validation on the func parameters.

Why don't we directly set the final status here itself rather than calling rejectTx().

The reasoning for using rejectTx() instead of directly setting the final status is to relieve the developer from the burden of understanding when we call "reject" and when we set the status directly.
Having this logic inside rejectTx() makes the reasoning self-explanatory.

it is possible to callhdr.TxID on nil

When data, hdr, envErr := serialization.UnwrapEnvelope(msg) returns without an error, hdr is never nil. So the error you refer to cannot happen.

I feel this is bit fragile. In fact, the debug() in IsStatusStoredInDB is accessing hdr.TxID and can result in panic if debug log is enabled. If you want to retain the call to rejectTx(), there has to be some validation on the func parameters.

debugTx() handles the case of nil header.
The only "fragile" case is when we reject with MALFORMED_BAD_ENVELOPE. In such a case, hdr==nil, and we rely on the fact that this status is not stored in the DB.

To make the code more robust, I added the rejectNonDBStatusTx() method and used it when the status is known in advance and it is not stored in the DB. This also eliminates the recursion.